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Introduction 


P<: (short for development and operations), like 
most new approaches, is only a buzzword for many 
people. Everyone talks about it, but not everyone knows what 
it is. In broad terms, DevOps is an approach based on lean and 
agile principles in which business owners and the develop- 
ment, operations, and quality assurance departments collabo- 
rate to deliver software in a continuous manner that enables 
the business to more quickly seize market opportunities and 
reduce the time to include customer feedback. Indeed, enter- 
prise applications are so diverse and composed of multiple 
technologies, databases, end-user devices, and so on, that 
only a DevOps approach will be successful when dealing with 
these complexities. Opinions differ on how to use it, however. 


Some people say that DevOps is for practitioners only; others 
say that it revolves around the cloud. IBM takes a broad and 
holistic view and sees DevOps as a business-driven soft- 
ware delivery approach — an approach that takes a new or 
enhanced business capability from an idea all the way to pro- 
duction, providing business value to customers in an efficient 
manner and capturing feedback as customers engage with the 
capability. To do this, you need participation from stakehold- 
ers beyond just the development and operations teams. A 
true DevOps approach includes lines of business, practitio- 
ners, executives, partners, suppliers, and so on. 


About This Gook 


In this book, I take a business-centric approach to DevOps. 
Today’s fast-moving world makes DevOps essential to all 
enterprises that must be agile and lean enough to respond 
rapidly to changes such as customer demands, market 
conditions, competitive pressures, or regulatory requirements. 


If you’re reading this book, I assume that you’ve heard about 
DevOps but want to understand what it means and how your 
company can gain business benefits from it. This book is 
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geared to executives, decision makers, and practitioners who 
are new to the field of DevOps, who seek more information 
about the approach, and who want to cut through the 

hype surrounding the concept to get to the meat of it. 


Icons Used in This Book 


You'll find several icons in the margins of this book. Here’s 
what they mean. 

ar 
The Tip icon points out helpful information on various 
aspects of DevOps. 


> 

ny 

7 Anything that has a Remember icon is something that you 
want to keep in mind. 


NING) 
RY 
The Warning icon alerts you to critical information. 


seh STy, 


s Mee 
& fiso, Technical Stuff material goes beyond the basics of DevOps. It 
v7 isn’t essential reading, however. 


Beyond the Book 


You can find additional information about DevOps (and about 
IBM’s approach to it) by visiting the following web pages: 
IBM DevOps Solution: www. ibm.com/ibm/devops/us/en 


4 DevOps — the IBM approach (white paper): ibm. co/ 
1a54r3m 


The Software Edge (study): http: //ibm.co/156Kdo0 
4 IBM DevOps Products: jazz .net/products/devops 
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Chapter 1 
What Is DevOps? 


In This Chapter 
Seeing a business need for DevOps 
Finding business value in DevOps 
Understanding DevOps principles 


M aking any change in “business as usual” is always hard 
and usually requires an investment. So whenever an 
organization adopts any new technology, methodology, or 
approach, that adoption has to be driven by a business need. 
To develop a business case for adopting DevOps, you must 
understand the business need for it, including the challenges 
that it addresses. In this chapter, I give you the foundation 
you need to start building your case. 


Understanding the Business 
Need for DevOps 


Organizations want to create innovative applications or ser- 
vices to solve business problems. They may want to address 
internal business problems (such as creating a better customer 
relationship management system) or to help their customers or 
end-users (such as by providing a new mobile app). 


Many organizations aren’t successful with software projects, 
however, and their failures are often related to challenges 

in software development and delivery. Although most enter- 
prises feel that software development and delivery are criti- 
cal, a recent IBM survey of the industry found that only 25 
percent believe that their teams are effective. This execution 
gap leads to missed business opportunities. 
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gore 


This problem is further amplified by a major shift in the types 
of applications that businesses are required to deliver, from 
systems of record to systems of engagement: 


Systems of record: Traditional software applications are 
large systems that function as systems of record, which 
contain massive amounts of data and/or transactions and 
are designed to be highly reliable and stable. Because these 
applications don’t need to change often, organizations can 
satisfy their customers and their own business needs by 
delivering only one or two large new releases a year. 


Systems of engagement: With the advent of mobile com- 
munications and the maturation of web applications, 
systems of record are being supplemented by systems 
of engagement, which customers can access directly and 
use to interact with the business. Such applications must 
be easy to use, high performing, and, systems require 
rapid change to address customers’ changing needs and 
evolving market forces. 


Because systems of engagement are used directly by custom- 
ers, they require intense focus on user experience, speed of 
delivery, and agility — in other words, a DevOps approach. 


Systems of engagement aren’t isolated islands and are often 
tied to systems of record, so rapid changes to systems of 
engagement result in changes to systems of record. Indeed 
any kind of system that needs rapid delivery of innovation 
requires DevOps. Such innovation is driven primarily by 
emerging technology trends such as cloud computing, mobile 
applications, Big Data, and social media, which may affect all 
types of systems. I discuss these emerging technologies in 
light of DevOps in Chapter 4. 


Recognizing the Business 
Value of DevOps 


DevOps applies agile and lean principles across the entire 
software supply chain. It enables a business to maximize the 
speed of its delivery of a product or service, from initial idea 
to production release to customer feedback to enhancements 
based on that feedback. 
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gore Because DevOps improves the way that a business delivers 
> value to its customers, suppliers, and partners, it’s an essen- 
tial business process, not just an IT capability. 


DevOps provides significant return on investment in three 
areas: 


Enhanced customer experience 
Increased capacity to innovate 


Faster time to value 


I discuss all three areas in the following sections. 


Enhanced customer experience 


Delivering an enhanced (that is, differentiated and engaging) 
customer experience builds customer loyalty and increases 
market share. To deliver this experience, a business must 
continuously obtain and respond to customer feedback, which 
requires mechanisms to get fast feedback from all the stake- 
holders in the software application that’s being delivered: cus- 
tomers, lines of business, users, suppliers, partners, and so on. 


In today’s world of systems of engagement (see “Understanding 
the Business Need for DevOps,” earlier in this chapter), this 
ability to react and adapt in an agile manner leads to enhanced 
customer experience and loyalty. 


Increased capacity to innovate 


Modern organizations use lean thinking approaches to increase 
their capacity to innovate. Their goals are to reduce waste and 
rework and to shift resources to higher-value activities. 


tt Sup, An example of a common practice in lean thinking is A-B test- 
3 es, ing, in which organizations ask a small group of users to test 
may \7 and rate two or more sets of software that have different capa- 
bilities. Then the better-capability set is rolled out to all users, 
and the unsuccessful version is rolled back. Such A-B testing 
is realistic only with efficient and automated mechanisms 
such as those that DevOps facilitates. 
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Faster time to value 


Speeding time to value involves developing a culture, prac- 
tices, and automation that allow for fast, efficient, and reli- 
able software delivery through to production. DevOps, when 
adopted as a business capability, provides the tools and cul- 
ture required to facilitate efficient release planning, predict- 
ability, and success. 


The definition of value varies from organization to organiza- 
tion and even from project to project, but the goal of DevOps 
is to deliver this value faster and more efficiently. 


Seeing How DevOps Works 


The DevOps movement has produced several principles that 
have evolved over time and are still evolving. Several solution 
providers, including IBM, have developed their own variants. 
All these principles, however, take a holistic approach to 
DevOps, and organizations of all sizes can adopt them. These 
principles are 

” Develop and test against production-like systems 

Deploy with repeatable, reliable processes 

Monitor and validate operational quality 


Amplify feedback loops 


I describe the principles in more detail in the following 
sections. 


Develop and test against 
production-like systems 


This principle stems from the DevOps concept shift left, in 
which operations concerns move earlier in the software deliv- 
ery life cycle, toward development (see Figure 1-1). 
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<= ‘Shift Left’ - Operational Concerns 


Figure 1-1: The shift-left concept moves operations earlier in the develop- 
ment life cycle. 





The goal is to allow development and quality assurance (QA) 
teams to develop and test against systems that behave like the 
production system, so that they can see how the application 
behaves and performs well before it’s ready for deployment. 


The first exposure of the application to a productionlike system 
should be as early in the life cycle as possible to address two 
major potential challenges. First, it allows the application to be 
tested in an environment that’s close to the actual production 
environment the application will be delivered to; and second, it 
allows for the application delivery processes themselves to be 
tested and validated upfront. 


From an operations perspective, too, this principle has tre- 
mendous value. It enables the operations team to see early in 
the cycle how their environment will behave when it supports 
the application, thereby allowing them to create a fine-tuned, 
application-aware environment. 


Deploy with repeatable, 
reliable processes 


As the name suggests, this principle allows development and 
operations to support an agile (or at least iterative) software 
development process all the way through to production. 
Automation is essential to create processes that are itera- 
tive, frequent, repeatable, and reliable, so the organization 
must create a delivery pipeline that allows for continuous, 
automated deployment and testing. I talk more about delivery 
pipelines in Chapter 3. 
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avr Frequent deployments also allow teams to test the deploy- 
ment processes themselves, thereby lowering the risk of 
deployment failures at release time. 


Monitor and validate 
operational quality 


Organizations typically are good at monitoring applications 
and systems in production because they have tools that 
capture production systems’ metrics in real time. But they 
monitor in a siloed and disconnected manner. This principle 
moves monitoring earlier in the life cycle by requiring that 
automated testing be done early and often in the life cycle to 
monitor functional and non-functional characteristics of the 
application. Whenever an application is deployed and tested, 
quality metrics should be captured and analyzed. Frequent 
monitoring provides early warning about operational and 
quality issues that may occur in production. 

se 
These metrics should be captured in a format that all 

business stakeholders can understand and use. 


Amplify feedback loops 


One goal of DevOps is to enable organizations to react and 
make changes more rapidly. In software delivery, this goal 
requires an organization to get quick feedback and then learn 
rapidly from every action it takes. This principle calls for 
organizations to create communication channels that allow all 
stakeholders to access and act on feedback. 


Development may act by adjusting its project plans or 
priorities. 


Production may act by enhancing the production 
environments. 


Business may act by modifying its release plans. 
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Chapter 2 


Looking at DevOps 
Capabilities 


In This Chapter 
Understanding the reference architecture of DevOps 


Considering four paths to DevOps adoption 


[: capabilities that make up DevOps are a broad set that 
span the software delivery life cycle. Where an organiza- 
tion starts with DevOps depends on its business objectives 
and goals — what challenges it’s trying to address and what 
gaps in its software delivery capabilities need to be filled. 


In this chapter, I look at a DevOps reference architecture and 
the various ways that it enables a business to use DevOps. 


Paths to DevOps Adoption 


A reference architecture provides a template of a proven solu- 
tion by using a set of preferred methods and capabilities. The 
DevOps reference architectures discussed in this chapter 
help practitioners access and use the guidelines, directives, 
and other material that they need to architect or design a 
DevOps platform that accommodates people, processes, and 
technology (see Chapter 3). 


A reference architecture provides capabilities through its 
various components. These capabilities in turn may be pro- 
vided by a single component or a group of components work- 
ing together. Therefore, you can view the DevOps reference 
architecture, shown in Figure 2-1, from the perspective of the 
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core capabilities that it’s intended to provide. As the abstract 
architecture evolves to concrete form, these capabilities are 
provided by a set of effectively enabled people, defined prac- 
tices, and automation tools. 


DevOps Life cycle 
Business Development/ Operations/ 
Customers Owners Test Production 


fun 
0%@69%69280e 
=— Continuous innovation, feedback, and improvements —> 
Plan and Measure Develop and Test Release and Deploy 


Monitor and Optimize 





Figure 2-1: DevOps reference architecture. 


The DevOps reference architecture shown in Figure 2-1 pro- 
poses the following four sets of adoption paths: 

Plan and measure 

Develop and test 

Release and deploy 

Monitor and optimize 


In the following sections, I take a detailed look at these adop- 
tion paths. 


Plan and Measure 


This adoption path consists of one practice that focuses on 
the lines of business and their planning processes: continuous 
business planning. 


Businesses need to be agile and able to react quickly to 
customer feedback. Consequently, many businesses today 
employ lean thinking techniques. These techniques involve 
starting small by identifying the outcomes and resources 
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needed to test the business vision or value, and then continu- 
ously adapting and adjusting based on customer feedback. 

To achieve these goals, organizations measure progress, find 
out what customers really want, and then shift direction by 
updating their business plans accordingly, allowing them to 
make continuous trade-off decisions in a resource constrained 
environment. 


Develop and Test 


This adoption path involves two practices: collaborative 
development and continuous testing. As such, it forms the 
core of development and quality assurance (QA) capabilities. 


Collaborative development 


Software delivery efforts in an enterprise involve large num- 
bers of cross-functional teams, including lines-of-business 
owners, business analysts, enterprise and software architects, 
developers, QA practitioners, operations personnel, security 
specialists, suppliers, and partners. Practitioners from these 
teams work on multiple platforms and may be spread across 
multiple locations. Collaborative development enables these 
practitioners to work together by providing a common set of 
practices and a common platform they can use to create and 
deliver software. 


One core capability included within collaborative development 
is continuous integration (see Figure 2-2), a practice in which 
software developers continuously or frequently integrate their 
work with that of other members of the development team. 


Component 
team build 
Component 
team build 


Figure 2-2: Collaboration via continuous integration. 






Integration 
build 
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Continuous integration was made popular by the agile move- 
ment. The idea is for developers to regularly integrate their 
work with that of the rest of the developers on their team 
and then test the integrated work. In the case of complex 
systems made up of multiple systems or services, developers 
also regularly integrate their work with other systems and 
services. Regular integration of results leads to early discov- 
ery and exposure of integration risks. In complex systems, it 
also exposes known and unknown risks — both technical and 
schedule-related. 


Continuous testing 


Continuous integration (see the preceding section) has sev- 
eral goals: 


Enable ongoing testing and verification of code 


Validate that the code produced and integrated with that 
of other developers and other components of the appli- 
cation functions and performs as designed 


Continuously test the application being developed 


Continuous testing means testing earlier and continuously 
across the life cycle, which results in reduced costs and short- 
ened testing cycles and achieved continuous feedback on 
quality. This occurs by adopting capabilities like automated 
testing and service virtualization. Service virtualization is the 
new capability for simulation of production-like environments 
and makes continuous testing feasible. 


Release and Deploy 


Release and deploy forms the adoption path where most of 
the root capabilities of DevOps originated. Continuous release 
and deployment take the concept of continuous integra- 

tion to the next step. The practice that enables release and 
deploy also enables the creation of a delivery pipeline (see 
Chapter 3). This pipeline facilitates continuous deployment 

of software to QA and then to production in an efficient, auto- 
mated manner. The goal of continuous release and deploy- 
ment is to release new features to customers and users as 
soon as possible. 
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Most of the tooling and processes that make up the core of 
DevOps technology exist to facilitate continuous integration, 
continuous release, and continuous deployment. I discuss 
these topics in more detail in later chapters. 


Monitor and Optimize 


<r 


The monitor and optimize adoption path includes two practices 
that allow businesses to monitor how released applications are 

performing in production and to receive feedback from custom- 
ers. This data allows the businesses to react in an agile manner 

and change their business plans as necessary. 


Continuous monitoring 


Continuous monitoring provides data and metrics to 
Operations, QA, Development, lines-of-business personnel, 
and other stakeholders about applications at different stages 
of the delivery cycle. 


These metrics aren’t limited to production. Such metrics 
allow stakeholders to react by enhancing or changing the fea- 
tures being delivered and/or the business plans required to 
deliver them. 


Continuous customer feedback 
and optimization 


The two most important types of information that a software 
delivery team can get are data about how customers use the 
application and feedback that those customers provide upon 
using the application. New technologies allow businesses to 
capture customer behavior and customer pain points right 

as they use the application. This feedback allows different 
stakeholders to take appropriate actions to improve the appli- 
cations and enhance customer experience. Lines of business 
may adjust their business plans, development may adjust the 
capabilities it delivers, and operations may enhance the envi- 
ronment in which the application is deployed. This continuous 
feedback loop is an essential component of DevOps, allowing 
businesses to be more agile and responsive to customer needs. 
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Chapter 3 
Adopting DevOps 


In This Chapter 
Making people more efficient 
Streamlining processes 
Choosing the right tools 


A dopting any new capability typically requires a plan that 
spans people, process, and technology. You can’t suc- 
ceed in adopting new capabilities — especially in an enterprise 
that has multiple, potentially distributed stakeholders — with- 
out taking into consideration all three aspects of the capabili- 
ties being adopted. 


In this chapter, I discuss the people, process, and technology 
aspects of DevOps. 


EMBER Although the name DevOps suggests development- and 
operations-based capabilities, DevOps is an enterprise capa- 
bility that spans all stakeholders in an organization, including 
business owners, architecture, design, development, quality 
assurance (QA), operations, security, partners, and suppliers. 
Excluding any stakeholder — internal or external — leads to 
an incomplete implementation of DevOps. 


People in DevOps 


This section addresses the people aspect of adopting DevOps, 
including creating the necessary culture. 
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DevOps culture 


At its root, DevOps is a cultural movement; it’s all about 
people. An organization may adopt the most efficient pro- 
cesses or automated tools possible, but they’re useless with- 
out the people who eventually must execute those processes 
and use those tools. Building a DevOps culture, therefore, is 
at the core of DevOps adoption. 


A DevOps culture is characterized by a high degree of col- 
laboration across roles, focus on business instead of depart- 
mental objectives, trust, and high value placed on learning 
through experimentation. 


Building a culture isn’t like adopting a process or a tool. It 
requires (for lack of a better term) social engineering of teams 
of people, each with unique predispositions, experiences, and 
biases. This diversity can make culture-building challenging 
and difficult. 


Lean and agile transformation practices are at the core of 
DevOps, and if your organization has already applied these, 
they can be leveraged to help adopt a DevOps culture. 


Identifying business objectives 


The first task in creating a culture is getting everyone headed 
in the same direction and working toward the same goal, 
which means identifying common business objectives for the 
team and the organization as a whole. It’s important to incent 
the entire team based on business outcomes versus conflict- 
ing team incentives. When people know what common goal 
they’re working toward and how their progress toward that 
goal is going to be measured, there are fewer challenges from 
teams or practitioners that have their own priorities. 


DevOps isn’t the goal. It helps you reach your goals. 


Chapter 4 highlights several new business challenges that 
DevOps addresses. Your organization can use those chal- 
lenges as a starting point to identify goals that it wants to 
achieve; then it can develop a common set of milestones 
toward those goals for different teams of stakeholders to use. 
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Measuring culture 


Measuring culture is extremely diffi- 
cult. How do you accurately measure 
improved collaboration or improved 
morale? You could take a direct mea- 
sure of attitudes and team morale by 
taking surveys, but surveys can have 
a high statistical error rate, as teams 
usually are small. 


Conversely, you can take an indirect 
measure by tracking how often a 


development team member reaches 
out to a member of an operations or 
QA team to collaborate on resolving 
an issue without going through offi- 
cial channels or multiple layers of 
management. 


Collaboration and communication 
across stakeholders — that’s the 
culture of DevOps. 
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Create an environment of sharing 


After identifying common business objectives, the next step in 
building a DevOps culture requires the leaders of the organi- 
zation to work with their teams to create an environment and 
culture of collaboration and sharing. 


Leaders must remove any self-imposed barriers to coopera- 
tion. Typical measurements reward operations teams for 
uptime and stability, and reward developers for new features 
delivered, but they pit these groups against each other. 
Operations knows that the best protection for production is 
to accept no changes, for example, and Development has little 
incentive to focus on quality. Replace these measurements 
with shared responsibility for delivering new capabilities 
quickly and safely. 


The leaders of the organization should further encourage col- 
laboration by improving visibility. Establishing a common set 
of collaboration tools is essential, especially when teams are 
geographically distributed and can’t work together in person. 
Giving all stakeholders visibility into a project’s goals and 
status is crucial for building a DevOps culture based on trust 
and collaboration. 


Sometimes, building a DevOps culture requires people to 
change. Those who are unwilling to change — that is, to adopt 
the DevOps culture — may need to be reassigned. 
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DevOps team 


The arguments for and against having a separate DevOps team 
are as old as the concept itself. Some organizations, such as 
Netflix, don’t have separate development and operations teams; 
instead, a single “NoOps” team owns both sets of responsibili- 
ties. Other organizations have succeeded with DevOps liaison 
teams, which resolve any conflicts and promote collaboration. 
Such a team may be an existing tools group or process group, or 
it may be anew team staffed by representatives of all teams that 
have a stake in the application being delivered. 


If you choose to have a DevOps team, your most important 
goal is to ensure that it functions as a Center of Excellence 
that facilitates collaboration without adding a new layer of 
bureaucracy or becoming the team that owns addressing all 
DevOps related problems — a development that would defeat 
the purpose of adopting a DevOps culture. 


Process in DevOps 


In the preceding section, I discussed the role of people and 
culture in adopting DevOps. Processes define what those 
people do. Your organization can have a great culture of col- 
laboration, but if people are doing the wrong things or doing 
the right things in the wrong way, failure is still likely. 


A vast number of processes are identified with DevOps — too 
many to cover in this book. This section discusses some of the 
key processes in light of their adoption across an enterprise. 


DevOps as a business process 


DevOps as a capability affects a whole business. It makes the 
business more agile and improves its delivery of capabilities 
to customers. You can extend DevOps further by looking at 

it as a business process. a collection of activities or tasks that 
produces a specific result (service or product) for customers. 


In the reference architecture introduced in Chapter 2, the 
DevOps business process involves taking capabilities from 
the idea (typically identified with business owners) through 
development and testing to production. 
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Although this business process isn’t mature enough to be cap- 
tured in a set of simple process flows, you should capture the 
process flows that your organization already uses to deliver 
capabilities. Then you can identify areas of improvement, 
both by improving the processes themselves and by introduc- 
ing automation (see the “Technology in DevOps” section, later 
in this chapter). 


Change management process 


Change management is a set of activities designed to control, 
manage, and track change by identifying the work products 
that are likely to change and the processes used to imple- 
ment that change. The change management process that an 
organization uses is an inherent part of the broader DevOps 
process flow. Change management drives the way the DevOps 
processes absorb and react to change requests and customer 
feedback. 


Organizations that have adopted application lifecycle manage- 
ment (ALM) already have well-defined and (probably) auto- 
mated change management processes in place. 


Change management should include processes that enable 
the following capabilities: 


 Work-item management 
Configurable work-item workflows 
Project configuration management 
Planning (agile and iterative) 


 Role-based artifact access control 


Traditional change management approaches tend to be limited 
to change request or defect management, with limited capabil- 
ity to trace the events between the change requests or defects 
and the associated code or requirements. These approaches 
don’t provide integrated work-item management across the life 
cycle or built-in capability to trace all types of assets. DevOps, 
however, requires all stakeholders to be able to view and col- 
laborate on all changes across the software development life 
cycle. 
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DevOps- or ALM-centric change management includes pro- 
cesses that provide work-item management for all projects, 
tasks, and associated assets — not just those affected by 
change requests or defects. It also includes processes that 
enable the enterprise to link work items to all artifacts, proj- 
ect assets, and other work items that are created, modified, 
referenced, or deleted by any practitioner who works on 
them. These processes give team members role-based access 
to all change-related information and also support iterative 
and agile project development efforts. 


DevOps practices 


Following are a few specific practices that you need to include 
when you adopt DevOps: 


Release planning 
Continuous integration 
Continuous delivery 
Continuous testing 


Continuous monitoring and feedback 


The following sections examine these practices in detail. 


Release planning 


Release planning is a critical business function, driven by 
business needs to offer capabilities to customers and the 
timelines of these needs. Therefore, businesses require well- 
defined release planning and management processes that 
drive release roadmaps, project plans, and delivery sched- 
ules, as well as end-to-end traceability across these processes. 


Most companies today accomplish this task by using spread- 
sheets and holding meetings (often, long ones) with all 
stakeholders across the business to track all business needs 
applications under development, their development status, 
and release plans. Well-defined processes and automation, 
however, eliminate the need for those spreadsheets and 
meetings, and enable streamlined and — more importantly — 
predictable releases. Leveraging lean and agile practices 

also results in smaller, more frequent releases, permitting 
enhanced focus on quality. 
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Continuous integration 


Continuous integration (described in Chapter 2) adds tremen- 
dous value in DevOps by allowing large teams of developers, 
working on cross-technology components in multiple loca- 
tions, to deliver software in an agile manner. It also ensures 
that each team’s work is continuously integrated with that of 
other development teams and then validated. Continuous inte- 
gration thereby reduces risk and identifies issues earlier in the 
software development life cycle. 


Continuous delivery 


Continuous integration naturally leads to the practice of con- 
tinuous delivery: the process of automating the deployment 

of the software to the testing, system testing, staging, and pro- 
duction environments. Although some organizations stop short 
of production, those that adopt DevOps generally use the same 
automated process in all environments to improve efficiency 
and reduce the risk introduced by inconsistent processes. 


In test environments, automating configuration, refreshing test 
data, and then deploying the software to the test environment 
followed by the execution of automated tests, speeds feedback 
cycles of test results back to development. 


Adopting continuous delivery typically is the most critical 
part of adopting DevOps. To many DevOps practitioners, 
DevOps is limited to continuous delivery, so most tools pro- 
moted as DevOps tools address only this process. As you 
see throughout this book, however, DevOps is much broader 
in scope. Continuous delivery is an essential component of 
DevOps but not the only component. 


Based on your organization’s business needs and pressing 
challenges, you may choose to start adoption with another of 
the processes or adoption paths described in Chapter 2. 


Continuous testing 
I introduced continuous testing in Chapter 2. From a process 
perspective, you need to adopt processes in three areas to 
enable continuous testing: 

Test environment provisioning and configuration 

Test data management 


Integration, functional, performance, and security testing 
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In an organization, QA teams need to determine what pro- 
cesses to adopt for each area. The processes that they adopt 
may vary from project to project, based on individual testing 
needs and on the requirements of service level agreements. 
Customer-facing applications may need more security testing 
than internal applications do, for example. Test environment 
provisioning and test data management are more important 
challenges for projects that use agile methodologies and prac- 
tice continuous integration than they are for projects that use 
waterfall methodology and test only once every few months. 
Likewise, function and performance test requirements for com- 
plex applications with components that have different delivery 
cycles are different from those for simple, monolithic web apps. 


Continuous monitoring and feedback 


Customer feedback comes in different forms, such as tick- 

ets opened by customers, formal change requests, informal 
complaints, and ratings in app stores. Especially due to the 
popularity of social media and app stores (see Chapter 4), 
businesses need well-defined processes to absorb the feed- 
back from myriad sources and incorporate them into software 
delivery plans. These processes also need to be agile enough 
to adapt to market and regulatory changes. 


Feedback also comes from monitoring data. This data comes 
from the servers running the application; from Development, 
QA, and Production; or from metrics tools embedded in the 
application that capture user actions. 


Data overload is possible, so businesses need data-capture 
and data-use processes that enhance their applications and 
the environments they run in. 


Continuous improvement 


In true lean-thinking fashion, process adoption isn’t a one-time 
action, but an ongoing process. An organization should have 
built-in processes that identify areas for improvement as the 
organization matures and learns from the processes it has 
adopted. Many businesses have process improvement teams 
that work on improving processes based on observations 

and lessons learned; others allow the teams that adopt the 
processes to self-assess and determine their own process- 
improvement paths. Regardless of the method used, the goal 
is to enable continuous improvement. 
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Measuring process adoption 


You can measure the success of pro- 
cess adoption by seeing whether a 
set of efficiency and quality metrics 
is improving over time. This type of 
measurement has two prerequisites: 


You must identify the right set 
of efficiency and quality met- 
rics. These metrics should really 


You can use any of several well- 
defined frameworks to measure pro- 
cess maturity. For DevOps-specific 
processes, models such as the new 
IBM DevOps Maturity Model can 
assess maturity. More information 
about the IBM maturity model is 
available at ibm. biz/BdDYbv. 





matter to the business. 


You need to establish a base- 
line against which to measure 
improvement. 








Technology in DevOps 


Technology enables people to focus on high-value creative 
work while delegating routine tasks to automation. Technology 
also allows teams of practitioners to leverage and scale their 
time and abilities. 


If an organization is building or maintaining multiple applica- 
tions, everything it does has to be repeatable, in a reliable 
manner, to ensure quality across all applications. It can’t start 
from scratch with each new release or bug fix for every appli- 
cation. The organization has to reuse assets, code, and prac- 
tices to be cost-effective and efficient. 


Standardizing automation also makes people more effective 
(see “People in DevOps,” earlier in this chapter). Organizations 
may experience turnover in employees, contractors, or 
resource providers; people may move from project to project. 
But a common set of tools allows practitioners to work any- 
where, and new team members need to learn only one set of 
tools — a process that’s efficient, cost-effective, repeatable, 
and scalable. 
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Infrastructure as Code 


Infrastructure as code is a core capability of DevOps that 
allows organizations to manage the scale and the speed with 
which environments need to be provisioned and configured to 
enable continuous delivery. 


Evolving around the notion of infrastructure as code is the 
notion of software-defined environments. Whereas infra- 
structure as code deals with capturing node definitions and 
configurations as code, software-defined environments use 
technologies that define entire systems made up of multiple 
nodes — not just their configurations, but also their defini- 
tions, topologies, roles, relationships, workloads and work- 
load policies, and behavior. 


Two kinds of automation tools are available for managing 
infrastructure as code: 


 Application- or middleware-centric tools: These tools 
usually are capable of managing as code both applica- 
tion servers and the applications that run on them. Such 
tools are specialized, bundled with libraries of typical 
automation tasks for the technologies that they support. 
They can’t perform low-level tasks such as configuring 
an operating-system (OS) setting, but they can fully auto- 
mate server and application-level tasks. 


Generic tools: These tools aren’t specialized for any 
technology and can be scripted to perform several kinds 
of tasks, all the way from configuring an OS on a virtual 
or physical node to configuring firewall ports. They 
require much more work up front than application- or 
middleware-centric tools do, but they can handle a 
greater range of tasks. 


Delivery pipeline 


A delivery pipeline consists of the stages an application goes 
through from development through to production. Figure 3-1 
shows a typical set of stages. These stages may vary from one 
organization to another, however, and may also vary from 
one application to another based on the organization’s needs, 
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software delivery process, and maturity. The level of automa- 
tion may also vary. Some organizations fully automate their 
delivery pipelines; others put their software through manual 
checks and gates due to regulatory or company requirements. 
You don’t have to address all stages at once. Start by focusing 
on the critical parts of organization — not everything all at 
once — and then gradually broaden to include all stages. 


Application Release Management 





Cloud Provisioning 


Application Deployment Automation 
: a 
I ] 
7 ~ T | : a = (l= 
4 es 


Development Build Package Test Stage Prod 
Repository Environment Environment Environment 


















































Figure 3-1: Stages of a typical DevOps delivery pipeline. 


A typical delivery pipeline has the stages described in the fol- 
lowing sections. 


Development environment 


An application’s development effort takes place in a develop- 
ment environment, which provides multiple tools that enable 
the developers to write and test code. Beyond the integrated 
development environment (IDE) tools that developers use to 
write code, this stage includes tools that enable collaborative 
development, such as tools for source control management, 
work-item management, collaboration, unit testing, and proj- 
ect planning. Tools in this stage typically are cross-platform 
and cross-technology, based on the type of development 
being undertaken. 


Build stage 


The build stage is where the code is compiled to create and 
unit test the binaries to be deployed. Multiple build tools 
may be used in this stage, based on cross-platform and cross- 
technology needs. Development organizations typically use 
build servers to facilitate the large number of builds required 
on an ongoing basis to enable continuous integration. 
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Package repository 


A package repository (also referred to as an asset repository 
or artifact repository) is acommon storage mechanism for the 
binaries created during the build stage. These repositories 
also need to store the assets associated with the binaries to 
facilitate their deployment, such as configuration files, 
infrastructure-as-code files, and deployment scripts. 


Test environment 


A test environment is where the QA, user acceptance, and 
development/testing teams do the actual testing. Many flavors 
of tools are used in this stage, based on QA needs. Here are a 
few examples: 


Test environment management: These tools facilitate 
provisioning and configuring the test environments. They 
include infrastructure-as-code technologies and (if the 
environment is in the cloud) cloud provisioning and man- 
agement tools. 


Test data management: For any organization that wants 
to enable continuous testing, managing test data is an 
essential function. The number of tests that can be run 
and the frequency with which they’re run are limited by 
the amount of data that’s available for testing and the 
speed at which that data can be refreshed. 


Integration, functional, performance, and security test- 
ing tools: Automated tools are available for each of these 
types of tests. These tools should be integrated with a 
common test asset management tool or repository where 
all test scenarios, test scripts, and associated results 
can be stored and traceability established back to code, 
requirements, and defects. 


Service virtualization: Modern applications aren’t 
simple, monolithic applications. They’re complex 
systems that are dependent on other applications, 
application servers, databases, and even third-party 
applications and data sources. Unfortunately, at test 
time, these components may be unavailable or costly. 
Service virtualization solutions simulate the behavior — 
functionality and performance — of select components 
within an application to enable end-to-end testing of 
the application as a whole. These tools create stubs 
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(virtual components) of the applications and services 
that are required for the tests to run. The behavior and 
performance of the application can be tested as it inter- 
acts with these stubs. IBM’s Rational Test Virtualization 
Server provides such Test Virtualization capabilities. 


Stage and production environments 


Applications are deployed in the staging and production envi- 
ronments. Tools used in these stages include environment 
management and provisioning tools. Tools for infrastructure 
as code also play a critical role in these stages, due to the large 
scale at which the environment in these stages exist. With 

the advent of virtualization and cloud technologies, stage and 
production environments can today be made up of hundreds 
or even thousands of servers. Monitoring tools allow organiza- 
tions to monitor the deployed applications in production. 


Deployment automation and 
release management 


Managing the automation of application deployment from one 
stage to the next requires specialized tools, some of which I 
discuss in the following sections. 


Deployment automation 


Deployment automation tools are the core tools in the DevOps 
space. Such tools perform orchestrated deployments and 
track which version is deployed on which node at any stage of 
the build and delivery pipeline. They can also manage the con- 
figurations of the environments of all the stages to which the 
application components must be deployed. 


Deployment automation tools manage the software compo- 
nents that get deployed; the middleware components and 
middleware configurations that need to be updated; the data- 
base components that need to be changed; and the configura- 
tion changes to the environments to which these components 
are to be deployed. These tools also capture and automate 
the processes to carry out these deployments and configura- 
tion changes. IBM UrbanCode Deploy is such a deployment 
automation tool. 
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Release management 


Orchestrating the release plans and deployments associated 
with each release requires coordination across the business, 
development, QA, and operations teams. Release manage- 

ment tools allow organizations to plan and execute releases, 





provide a single collaboration portal for all stakeholders in 

a release, and provide traceability for a release and its com- 
ponents across all stages of the build and delivery pipeline. 
IBM UrbanCode Release provides such release management 


capabilities. 





Measuring technology adoption 


and reliability of tasks — some- 
thing that isn’t always possible with 
manual tools. Finally, using an inte- 
grated set of automated tools facili- 
tates collaboration, traceability, and 
improved quality. 


Measuring return on investment 
tools and technology is fairly 
straightforward. Typically, you can 
measure the efficiencies created by 
automation. Also, automated tools 
allow you to enhance the scalability 
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Chapter 4 


Solving New Problems 
with DevOps 


In This Chapter 
Coping with the cloud 
Enabling mobile applications 
Dealing with ALM processes 
Managing multiple-tier applications 
Working with supply chains 
Navigating the Internet of Things 


D-: originated in so-called born on the web companies 
(companies that originated on the Internet) such as Etsy, 
Flickr, and Netflix. These companies, while solving complex 
technology challenges at a very large scale, had fairly simple 
architectures — unlike large enterprises that grew around 
legacy systems and/or through acquisitions and mergers, with 
complex multi-technology systems that had to work together. 
These challenges are further aggravated by the demands 
being put on modern enterprises by new technologies like 
cloud and mobile and application delivery models such as 
software supply chains. 


This chapter explores some of these challenges that enterprises 
face and that DevOps can help solve. 


Cloud Technology 


One of the most critical changes that has affected DevOps 
(and actually helped it mature at the same time) is Cloud. 
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The pervasiveness of cloud technology, private, public, and 
hybrid, has enabled organizations to provision environments 
on demand. In traditional organizations that use physical serv- 
ers, requesting a new server is a complex, time-consuming 
process. It may take days or even weeks to requisition a new 
physical server, install and set up the operating system (OS), 
and configure all the software required to deploy the applica- 
tion. Virtualization and Cloud solve that problem to a large 
extent. This has led to tremendous growth in the scale by 
which the environments to which applications are deployed 
are used. This scale has necessitated automation on software 
deployment tasks, which DevOps addresses. 


At the same time the advent of cloud actually facilitates con- 
tinuous deployment and provides easier access to production- 
like environments during the development and testing stages 
of the delivery pipeline. It has also led to developer self-service 
in enterprises typically known for siloed separation of respon- 
sibilities. With cloud technologies, a developer can not only 
invoke an automated build, but also request the provisioning 
and configuration of a productionlike environment in the cloud 
and then deploy the application being built to it — all without 
any direct involvement by the operations team. Both of these 
capabilities provided by cloud facilitate DevOps adoption. 


Mobile Applications 


In an enterprise, mobile apps are typically not stand alone apps. 
They have very little business logic on the mobile device itself 
and serve more as front-ends to a multiple enterprise applica- 
tions already in use by the enterprise. These back-end enter- 
prise applications may range from transaction processing 
systems to employee portals to customer acquisition systems. 
Mobile development and delivery is complex and requires a 
set of dependent services to be delivered in a coordinated 
fashion in a reliable and efficient manner. 


For enterprise mobile apps, release cycles and new feature 
releases need to be coordinated with those of the enterprise 
applications and services that the mobile apps interact with. 
Therefore, DevOps adoption should include mobile-app teams 
as first-class citizens and participants along with the rest of 
the enterprise software development teams. 
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DevOps and app stores 


One unique aspect of mobile apps 
is the need for deployment to app 
stores. Most mobile apps can't be 
deployed directly to mobile devices; 
they have to go through a vendor- 
managed app store. Apple introduced 
this distribution format with its App 
Store (and locked its devices to 
prevent direct installation of apps by 
app developers or vendors). 


Device manufacturers such as 
Research In Motion and Microsoft, 
which once allowed direct app 
installation, now follow the Apple model. 
This situation adds an asynchronous 


step to the deployment process. 
Developers can no longer deploy 
updates to an app on demand. Even 
for critical bug fixes, new app versions 
have to go through an app store’s 
submission and review processes. 
Continuous delivery becomes 
submitting and waiting. Continuous 
deployment to development and testing 
remains available, however, with the 
test environment being simulators for 
the devices on which the application 
will be deployed or banks of physical 
devices. 








MBER 


No specific DevOps concepts or principles apply solely to 


mobile apps. Mobile apps, however, add to the need for 
DevOps due to their inherent short development life cycles 


and rapid change. 


ALM Processes 


Application lifecycle management (ALM) is a set of processes 
employed to manage the life of an application as it evolves 
from an idea (a business need) to an application that’s deployed 
and eventually under maintenance. Hence, looking at DevOps 
as an end-to-end business capability makes ALM part of the 
DevOps process. 


The five imperatives of ALM (jazz.net/library/article/637) 
apply to a DevOps-centric view of application delivery. The 
five imperatives are 


Real-time planning 


Life-cycle traceability 
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 In-context collaboration 
Development intelligence 


Continuous process improvement 


Describing these imperatives in detail is beyond the scope of 
this book. Real-time planning maps to the plan-and-measure 
adoption path. The life cycle traceability and in-context col- 
laboration imperatives map to develop-and-test, and develop- 
ment intelligence and continuous process improvement map 
to monitor and optimize. Check out Chapter 2 for more on 
these paths. 


Multiple-Tier Applications 


In a typical large IT shop, it’s not uncommon to find multiple- 
tier applications that span many platforms, each with its own 
unique development process, tools, and skill requirements. 
These multi-tier systems often integrate applications on the 
web, desktop, and mobile applications on the front-end and 
back-end systems such as packaged applications, data ware- 
house systems, applications running on mainframes, and 
midrange systems. Managing and coordinating the releases of 
the parts of multiple-tier systems, many of which may be on 
different platforms, can be overwhelming even for the most 
disciplined IT organization. 


A sensible approach is to follow automated, consistent build, 
configure, and deployment processes through all stages of 
development. This approach ensures that you’re building 

all the parts you need — and only the parts you need. It also 
ensures that the application remains whole as changes come 
in and the project moves through the cycle of testing, QA, and 
production. IBM UrbanCode Deploy has an application model 
that helps automate the complex deployment of multiple-tier 
applications. 


Maintaining separate tools for different teams based on plat- 
form is a reality in today’s multi-platform, multi-vendor world. 
This is where open platforms such as IBM Jazz, can integrate 
disparate tools to provide a unified solution. Consistent 
deployment practices can help ensure that teams are using 
reliable, repeatable deployment across platforms to provide 
true business value. 
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Supply Chains 


With the increasing use of outsourcing and strategic partner- 
ships to supply skills and capabilities to an enterprise, soft- 
ware supply chains are becoming the norm. A supply chain 

is a system of organizations, people, technology, activities, 
information, and resources involved in moving a product or 
service from supplier to customer. The various suppliers in 
the chain may be internal or external to the enterprise. 


In an organization that has adopted a supply-chain model 

for delivering software, adopting DevOps can be a challenge, 
because the relationships among suppliers are managed 
more by contracts and service level agreements than by col- 
laboration and communication. Such an organization can 

still adopt DevOps, however. The core project teams retain 
ownership of the planning and measurement capabilities, with 
other capabilities being shared among the other suppliers. In 
the delivery pipeline, different suppliers may own different 
stages of the pipeline. Using common tool sets and a common 
asset repository is therfore essential. A work-item manage- 
ment tool, for example, provides reporting on all items being 
worked on by all suppliers, as well as transfer of ownership 
of work items across suppliers. Using a common asset reposi- 
tory provides a mechanism for passing assets through the 
pipeline, enabling continuous delivery. 


The Internet of Things 


The next big step for DevOps is its evolution into the systems 
or embedded-devices space. When the Internet started, most 
of the data shared on it was human-generated. Today, innu- 
merable Internet-connected devices (such as sensors and 
actuators) generate much more data than humans do. This 
network of inter-connected devices on the Internet is com- 
monly referred to as the Internet of Things. 


In this space, DevOps is potentially even more essential, due 
to the co-dependence of the hardware and the embedded 
software that runs on it. DevOps principles ensure that the 
embedded software delivered to the devices is high-quality 
software with the right engineering specifications. 
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Operations, in this case, is replaced by hardware or systems 
engineers who design and build custom hardware for the 
devices. Collaboration between the development and testing 
teams and the systems engineers is crucial to ensure that 
hardware and software are developed and delivered in a coor- 
dinated manner despite hardware and software development 
needing to follow different delivery cycles. The development 
and testing needs for continuous delivery and testing remain 
the same. Simulators are used to test software and hardware 


during development. 











Anti-patterns 


In the real world, there are always 
limitations to adoption of DevOps 
principles. Some of these limitations 
are functions of the industries and 
environments in which a business 
exists, such as regulatory compli- 
ance, complex hardware systems, 
or immature software delivery capa- 
bilities. In such cases, DevOps needs 
to be adopted in light of anti-patterns 
(ineffective or counterproductive 
patterns) that may not be accept- 
able for an organization, based on its 
business needs. 


Water-SCRUM-fall 


Forrester (www. forrester.com), 
a global research and advisory 
company, coined the term Water- 
SCRUM-fall to describe the current 
state of adoption of agile software 
development methodologies. From 
a DevOps perspective, this means 


that whereas development teams 
may have adopted agile practices, 
the teams around them may still 
have manual, waterfall-style pro- 
cesses that don’t allow for continu- 
ous delivery. In several enterprises, 
this situation results from the corpo- 
rate culture. A company that adopts 
DevOps must embed manual pro- 
cesses in broader DevOps practices. 


NoOps 


In a NoOps organization, Operations 
is eliminated as a separate depart- 
ment, and its responsibilities are 
merged into those of Development. 
Netflix, an Internet television pro- 
vider, is a proponent of this method. 
NoOps may work well for some 
organizations, but some waiting is 
involved to see if this organizational 
model will have wider practical 
appeal. 
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Chapter 5 
Ten DevOps Myths 


In This Chapter 
Understanding what DevOps is for 
Knowing what DevOps isn’t for 


[:: DevOps movement is young and still emerging, espe- 
cially among enterprises. Like any new movement or 
trend, it has attracted myths and fallacies. Some of these 
myths may have originated in companies or projects that 
tried and failed to adopt DevOps. What’s true in one situa- 
tion, however, may not necessarily be true in others. Here are 
some common myths about DevOps — and the facts. 


DevOps Is Only for “Born 
on the Web” Shops 


What is generally referred to as DevOps originated in “born 
on the web” companies (companies that originated on the 
Internet) such as Etsy, Netflix, and Flickr. Large enterprises 
have been using DevOps-aligned principles and practices to 
deliver software for decades, however. Furthermore, current 
DevOps principles, as described in this book, have a level of 
maturity that makes them applicable to large enterprises that 
have multiple-platform technologies and distributed teams. 


DevOps Is Operations 
Learning How to Code 


Operations teams have always written scripts to manage 
environments and repetitive tasks, but with the evolution 
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of infrastructure as code, operations teams saw a need to 
manage these large amounts of code with software engineer- 
ing practices such as versioning code, check-in, check-out, 
branching, and merging. Today, a new version of an environ- 
ment is created by an operations team member by creating 
a new version of the code that defines it. This doesn’t mean, 
however, that operations teams need to learn how to code in 
Java or C#. Most infrastructure-as-code technologies use lan- 
guages like Ruby, which are relatively easy to pick up, espe- 
cially for people who have scripting experience. 


DevOps Is Just for Development 
and Operations 


Although the name suggests a development-plus-operations 
origin, DevOps is for the whole team. All stakeholders in the deliv- 
ery of software — lines of business, practitioners, executives, 
partners, suppliers, and so on — also have a stake in DevOps. 


DevOps Isn’t for ITIL Shops 


Some people fear that DevOps capabilities such as continuous 
delivery are incompatible with the checks and processes pre- 
scribed by the Information Technology Infrastructure Library 
ATIL), a set of documented best practices for IT service man- 
agement. In reality, ITIL’s life cycle model is compatible with 
DevOps. Most of the principles defined by ITIL align very well 
with DevOps principles. ITIL has, however, received a bad repu- 
tation in some organizations due to being implemented predom- 
inately with slow, waterfall processes that didn’t allow for rapid 
changes and improvement. Aligning such practices between 
development and operations is the essence of DevOps. 


DevOps Isn’t for Regulated 
Industries 


Regulated industries have an overarching need for checks 
and balances and for approvals from stakeholders who ensure 
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compliance and auditability. Adopting DevOps actually 
improves compliance, if it’s done properly. Automating pro- 
cess flows and using tools that have built-in capability to cap- 
ture audit trails can help. 


Organizations in regulated industries will always have manual 
checkpoints or gates, but these elements aren’t incompatible 
with DevOps. 


DevOps Isn’t for Outsourced 
Development 


ar 


Outsourced teams should be viewed as suppliers or capability 
providers in the DevOps delivery pipeline. Organizations should 
ensure, however, that the practices and processes of the supplier 
teams are compatible with those of their internal project teams. 


Using common release planning, work-item management, and 
asset repository tools significantly improves communication 
and collaboration between lines of business and supplier and 
project teams, enabling DevOps practices. Using application 
release management tools can greatly improve an organiza- 
tion’s ability to define and coordinate the entire release pro- 
cess across all participants. 


No Cloud Means No DevOps 


When you think of DevOps, you often think of Cloud because 
of its ability to dynamically provision infrastructure resources 
for developers and testers to rapidly obtain test environments 
without waiting days/weeks for a manual request to be fulfilled. 
However, Cloud isn’t necessary to adopt DevOps practices as 
long as an organization has efficient processes for obtaining 
resources for deploying and testing application changes. 


Virtualization itself is optional. Continuous delivery to physical 
servers is possible if the servers can be configured and deployed 
to at the necessary speed. 
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DevOps Isn't for Large, 
Complex Systems 


Complex systems require the discipline and collaboration that 
DevOps provides. Such systems typically have multiple soft- 
ware and/or hardware components, each of which has its own 
delivery cycles and timelines. DevOps facilitates coordination 
of these delivery cycles and system-level release planning. 


DevOps Is Only about 
Communication 


¢ MBER 


Some members of the DevOps community have coined humor- 
ous terms such as ChatOps (teams carry out all communications 
through communication tools like Internet Relay Chat) and 
HugOps (DevOps focuses only on collaboration and communi- 
cation). These terms stem from the misconception that 
communication and collaboration solve all problems. 


DevOps depends on communication, but better communica- 
tion coupled with wasteful processes doesn’t lead to better 
deployments. 


DevOps Means Continuous 
Change Deployment 


This misconception comes from organizations that deploy 
only web applications. Some of these companies proudly state 
on their websites that they deploy to production daily. Daily 
deployment, however, is not only impractical in large orga- 
nizations that deploy complex applications, but may also be 
impossible due to regulatory or company restrictions. DevOps 
isn’t just about deployment, and it’s certainly not just about 
deploying continuously to production. Adopting DevOps 
allows organizations to release to production when they want 
to and not based on a particular date marked on a calendar. 
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The world runs on software 


Today's fast-moving world makes DevOps essential 
for any business aspiring to be agile and lean in order 
to respond rapidly to changing customer and 
marketplace demands. DevOps helps you achieve 
continuous delivery of software-driven innovation. 
This book helps you understand DevOps and how 
your organization can gain real business benefits 
from it. You also discover how a holistic view of 
DevOps that encompasses the entire software 
delivery life cycle - from ideation and the conception 
of new business capabilities to implementation in 
production — can bring competitive advantage in a 
continuous delivery world. 


e Exceed customer expectations — deliver 
higher-quality experiences 


e Meet the needs of the business — respond 
to dramatic increases in software delivery 
frequency and volume 


e Leverage new technology trends — use 
mobile, cloud, big data, and social 


Establish better collaboration — engage 
stakeholders across the software delivery 
life cycle 
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